<table class="configuration table table-bordered">
    <thead>
        <tr>
            <th class="text-left" style="width: 20%">Key</th>
            <th class="text-left" style="width: 15%">Default</th>
            <th class="text-left" style="width: 10%">Type</th>
            <th class="text-left" style="width: 55%">Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><h5>pulsar.source.autoCommitCursorInterval</h5></td>
            <td style="word-wrap: break-word;">5000</td>
            <td>Long</td>
            <td>This option is used only when the user disables the checkpoint and uses Exclusive or Failover subscription. We would automatically commit the cursor using the given period (in ms).</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.enableAutoAcknowledgeMessage</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>Flink commits the consuming position with pulsar transactions on checkpoint. However, if you have disabled the Flink checkpoint or disabled transaction for your Pulsar cluster, ensure that you have set this option to <code class="highlighter-rouge">true</code>.<br />The source would use pulsar client's internal mechanism and commit cursor in two ways.<ul><li>For <code class="highlighter-rouge">Key_Shared</code> and <code class="highlighter-rouge">Shared</code> subscription, the cursor would be committed once the message is consumed.</li><li>For <code class="highlighter-rouge">Exclusive</code> and <code class="highlighter-rouge">Failover</code> subscription, the cursor would be committed in a given interval.</li></ul></td>
        </tr>
        <tr>
            <td><h5>pulsar.source.maxFetchRecords</h5></td>
            <td style="word-wrap: break-word;">100</td>
            <td>Integer</td>
            <td>The maximum number of records to fetch to wait when polling. A longer time increases throughput but also latency. A fetch batch might be finished earlier because of <code class="highlighter-rouge">pulsar.source.maxFetchTime</code>.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.maxFetchTime</h5></td>
            <td style="word-wrap: break-word;">10000</td>
            <td>Long</td>
            <td>The maximum time (in ms) to wait when fetching records. A longer time increases throughput but also latency. A fetch batch might be finished earlier because of <code class="highlighter-rouge">pulsar.source.maxFetchRecords</code>.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.partitionDiscoveryIntervalMs</h5></td>
            <td style="word-wrap: break-word;">30000</td>
            <td>Long</td>
            <td>The interval (in ms) for the Pulsar source to discover the new partitions. A non-positive value disables the partition discovery.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.transactionTimeoutMillis</h5></td>
            <td style="word-wrap: break-word;">10800000</td>
            <td>Long</td>
            <td>This option is used in <code class="highlighter-rouge">Shared</code> or <code class="highlighter-rouge">Key_Shared</code> subscription. You should configure this option when you do not enable the <code class="highlighter-rouge">pulsar.source.enableAutoAcknowledgeMessage</code> option.<br />The value (in ms) should be greater than the checkpoint interval.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.verifyInitialOffsets</h5></td>
            <td style="word-wrap: break-word;">WARN_ON_MISMATCH</td>
            <td><p>Enum</p></td>
            <td>Upon (re)starting the source, check whether the expected message can be read. If failure is enabled, the application fails. Otherwise, it logs a warning. A possible solution is to adjust the retention settings in Pulsar or ignoring the check result.<br /><br />Possible values:<ul><li>"FAIL_ON_MISMATCH"</li><li>"WARN_ON_MISMATCH"</li></ul></td>
        </tr>
    </tbody>
</table>
